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ABSTRACT 


Navy  Warfare  Development  Command  has  established  Web- 
Enabled  Doctrine  (WED)  in  an  effort  to  enable  the  Navy' s 
transition  from  platform-centric  operations  to  Network 
Centric  Operations.  The  focus  of  this  research  is  to 
describe,  analyze,  and  evaluate  the  current  process  of 
developing  Navy  Doctrine  and  whether  that  process  can  be 
enhanced  with  a  commercially  available  distributive 
collaborative  technology  (DCT)  .  The  goal  of  WED  is  to 
ensure  that  Navy  Doctrine  remains  operationally  relevant 
and  directly  connected  with  the  Fleet.  WED  hopes  to 
accomplish  this  by  active  Fleet  participation  in  doctrinal 
development  and  reducing  timelines.  The  Chief  of  Naval 
Operations  has  set  forth  several  priorities  for  the  21®^ 
century  Navy,  which  include  service  unification,  improved 
current  and  future  readiness,  and  the  leveraging  of 
enabling  technologies.  Several  commercially  available  DCT 
products  appear  promising  to  enable  the  Navy' s 
transformation  to  web  based  Doctrine  development.  This 
research  focuses  on  one  such  product  to  determine  the 
adaptability  of  a  DCT  to  the  Navy  Doctrine  process.  The 
process  uses  an  information  system  network  that  allows 
personnel  the  ability  to  remain  readily  engaged  in  the  form 
of  discussion  groups  during  doctrinal  development.  This 
reduces  cost,  time,  and  incorporates  lessons  learned  from 
subject  matter  experts  in  the  Fleet. 
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I .  INTRODUCTION 


The  introduction  of  a  new  technology  into  the 
military  places  in  jeopardy  --  and  indeed  may 
even  destroy--many  long-standing  "mores  and 
structures"  of  the  established  military  society. 

-  Elting  Morison  [Ref.  1]  . 

A.  PURPOSE 

September  11,  2001,  introduced  the  United  States 

(U.S.)  to  a  new  kind  of  war.  The  U.S.  has  undertaken  the 
challenge  of  locating  and  bringing  to  justice  terrorist 
networks  and  those  who  harbor  them.  The  first  step  in  this 
challenge  is  Operation  Enduring  Freedom.  The  involvement 
of  U.S.  Armed  Forces  in  disabling  a  terrorist  network 
differs  from  the  traditional  warfare  of  the  past.  This 
fundamental  shift  in  strategy.  Doctrine  and  tactics 
characterizes  an  ongoing  trend  in  the  revolution  in 
military  affairs  (RMA) [Ref.  2:p.  125] . 

The  Navy  is  aggressively  pursuing  the  benefits  of  the 
RMA.  The  RMA  revolves  around  information.  Information, 
information  processing,  and  communications  networks  are  at 
the  core  of  every  military  activity  [Ref.  3:p.  8]  . 

Attaining  Information  Superiority  implies  transforming 
information  into  superior  knowledge  and  decisions  [Ref. 
3:p.  8]  .  Long  term  success  requires  translation  of  this 

information  and  knowledge  into  Doctrine  through  concept 
development . 

Military  Doctrine  plays  a  critical  role  in  how  the 
U.S.  will  employ  its  Armed  Forces  in  its  war  against 
terrorism.  Doctrine  provides  commanders  the  knowledge  base 
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needed  to  process  information  and  employ  courses  of  action 
(COA) .  Without  Doctrine,  commanders  would  have  to  go 
through  lengthy  and  timely  steps  such  as:  gathering  and 

evaluating  information,  providing  a  COA,  submitting  it  for 
approval  up  the  chain  of  command  (COC) ,  waiting  for  a 
response,  and,  based  on  the  response,  gathering  assets 
necessary  to  fulfill  the  COA,  before  finally  executing 
actions.  Doctrine  already  incorporates  these  steps  and 
provides  guidelines  for  COAs .  The  inputs  to  military 
Doctrine  include  current  policy,  available  resources, 
current  strategy,  current  Doctrine,  threats,  history  and 
lessons  learned,  strategic  traditions,  fielded  and  emerging 
technology,  geography  and  demographics,  and  type  of 
government  [Ref.  4:p.  30]. 

The  war  on  terrorism  represents  an  asymmetrical  type 
of  warfare  that  U.S.  forces  must  deal  with  in  the  future. 
U.S.  forces  have  two  choices:  rely  on  Doctrine  already  in 
place  or  develop  and  implement  Doctrine  as  the  war 
continues.  To  ensure  military  Doctrine  remains  a  living, 
fluid  document  demands  that  the  military  to  do  the  latter. 
In  order  for  Doctrine  to  be  effective,  a  force  must  conduct 
parallel  technological  and  doctrinal  development  [Ref.  5:p. 
17]  . 

The  Navy  Warfare  Development  Command  (NWDC)  has 
established  Web-Enabled  Doctrine  (WED)  in  an  effort  to 
enable  the  Navy' s  transition  from  platform-centric 
operations  (PCO)  to  Network  Centric  Operations  (NCO) .  The 
Navy's  traditional  Doctrine  development  process  consisted 
of  thirteen  steps,  which  resulted  in  a  slow,  timeline 
driven  process.  NWDC  has  embraced  the  concept  of  WED  to 
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speed  this  process  up.  WED  is  to  be  content  driven.  The 
WED  breaks  new  ground  by  incorporating  widespread  input 
into  its  development  of  Doctrine.  NWDC  envisions  the  WED 
to  be  "authored"  by  the  Eleet,  to  include  widespread 
deckplate  level  engagement  in  the  process;  WED  should 
reduce  the  process  timeline  to  days  or  weeks  vice  months  or 
years,  become  a  responsive  system,  and  maintain  relevant, 
current  Doctrine  and  Tactics  Techniques  and  Procedures 
(TTPs)  [Ref.  6] . 

There  are  many  commercial  off  the  shelf  (COTS) 
distributive  collaborative  technologies  (DCT)  available. 
If  implemented  appropriately  a  COTS  DCT  can  enable  the  WED 
process.  The  primary  focus  of  this  research  is  to 
determine  whether  COTS  DCT  have  the  potential  to  more 
effectively  and  efficiently  enable  the  Navy  Doctrine 
process.  The  success  of  this  dynamic  development  process 
is  important  in  today's  RMA  because  a  lack  of  Doctrine 
development  either  can  stifle  an  emerging  RMA  or  lead  to 
defeat  by  a  force  that  has  taken  advantage  of  an  RMA  [Ref. 
5:p.  17]  . 

B.  RESEARCH  QUESTIONS 

This  study  provides  baseline  knowledge  of  the  Navy 
Doctrine  process.  This  research  examines  how  to  determine 
COTS  dot's  adaptability  to  the  Navy  Doctrine  process. 

1 .  Primary 

Do  commercial  off  the  shelf  distributed  collaborative 
technologies  have  the  potential  to  more  effectively  and 

efficiently  enable  the  Navy  Doctrine  process? 
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2 .  Secondary 

•  What  processes  are  involved  in  Navy  Doctrinal 
development? 

•  How  can  a  COTS  DCT  improve  the  Doctrine  process? 

C.  THESIS  OUTLINE 

This  study  begins  with  a  description  of  the  role 

Doctrine  plays  in  the  U.S.  Navy  in  Chapter  II.  This 
section  of  the  study  reviews  the  literature,  including 
Naval  Warfare  Publications.  A  flowchart  represents  the 
traditional  Navy  Doctrine  process. 

Chapter  II  continues  with  a  brief  description  and 

justification  of  NCO.  Research  for  the  NCO  portion  of  the 
study  consisted  of  reviewing  a  Capstone  Article,  relevant 
literature,  NWDC' s  website,  and  various  other  websites. 
Leaders  in  today's  Navy  believe  the  future  lies  in  NCO. 
The  Navy's  shift  from  PCO  to  NCO  leads  to  the  Navy  after 
Next.  The  WED  is  a  major  step  down  the  road  to  NCO. 

Chapter  II  concludes  with  a  description  of  U.S.  Navy 
doctrinal  development  process.  This  is  divided  into  two 
sections.  The  first  section  describes  the  doctrinal 
development  process  that  NWDC  has  used  since  1998.  This 
process  is  referred  to  as  the  traditional  doctrinal 
process.  The  second  section  concludes  with  the  WED 

process.  The  WED  process  has  been  in  place  since  February 
of  2001.  The  model  of  the  WED  process  is  being  used  to 
facilitate  the  future  development  of  other  U.S.  Navy 

publications.  Presently  WED  is  a  web-based  newsgroup  model 
designed  to  increase  Fleet  participation  in  the  doctrinal 
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development  process.  Research  for  this  portion  of  the 

study  consisted  of  a  literature  review,  the  NWDC  website, 
PowerPoint  presentations,  and  email  correspondence. 

Chapter  III  begins  by  defining  and  discussing  the 
purpose  of  COTS  and  DCT .  DCTs  are  becoming  commonplace 
throughout  the  civilian  sector  and  are  credited  with  making 
the  decision  processes  more  efficient  and  effective.  Due 
to  rapid  technological  developments,  COTS  products  appear 
to  offer  system  enhancements  faster  than  products  of  custom 
development.  This  section  explores  the  benefits  and 

burdens  of  COTS  products  followed  by  a  product  overview  of 
a  COTS  DCT. 

Chapter  IV  examines  the  applicability  of  a  COTS  DCT 
product  to  the  Doctrine  development  process.  The  chapter 
investigates  how  a  COTS  DCT  can  be  adapted  to  the  Navy' s 
doctrinal  process.  The  model  chosen  for  this  study  is 
VITEPROJECT.  VITEPROJECT  is  used  as  an  exemplar  to 
demonstrate  the  benefits  of  using  a  COTS  DCT  in  the 
Doctrine  development  process. 

Chapter  V,  the  final  chapter,  presents  conclusions  and 
recommendations  based  on  the  analysis  of  applying  a  COTS 
DCT  to  the  Navy's  doctrinal  process.  A  discussion  of  how 
COTS  can  improve  WED  is  included.  Areas  for  further 
research  are  discussed. 

D .  METHODOLOGY 

Information  collected  in  this  study  includes  a 

literature  review,  interviews,  email  correspondence,  and 

information  gathered  via  the  web.  The  information 

collected  for  the  background  of  Navy  Doctrine  and  WED  were 
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gathered  through  literature  reviews,  PowerPoint 
presentations  from  the  NWDC  website,  and  interviews  through 
email  correspondence.  Information  collected  for  COTS  and 
DCT  were  gathered  through  a  literature  review.  Data 
collected  for  Appmail  were  gathered  by  a  literature  review, 
interviews  and  at  the  Zaplet  website. 

An  unstructured  interview  was  conducted  with  Zaplet ' s 
Vice  President  of  Sales  and  Co-founder  into  COTS  DCT  as  an 
evolving  technology.  The  interview  also  provided  a 
thorough  explanation  of  their  DCT. 

The  comparison  and  analysis  portion  of  this  study  uses 
VITEPROJECT  software.  Two  models  were  derived  to 
illustrate  the  traditional  Doctrine  process  with  and 
without  a  COTS  DCT  product. 

E.  EXPECTED  BENEFITS  OF  THIS  THESIS 

This  thesis  provides  a  stepping-stone  for  COTS 
adaptability  to  Naval  systems.  With  greater  collaborative 
abilities,  future  face-to-face  meetings  are  likely  to  occur 
less  frequently  and  allow  more  on  station  time  for 
warfighters . 

This  thesis  was  motivated  by  the  desire  for  Navy 
Doctrine  to  remain  a  living,  fluid  knowledge  base. 
Adapting  a  COTS  DCT  to  the  Navy  Doctrine  process  seems  to 
be  a  promising  approach  to  ensuring  the  parallel 
development  of  technology  and  Doctrine. 
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II .  BACKGROUND 


A.  THE  ROLE  OF  DOCTRINE  IN  THE  U.S.  NAVY 


Webster's  Dictionary  defines  Doctrine  as,  "a  principle 
or  position  or  the  body  of  principles  in  a  branch  of 
knowledge  or  a  system  of  belief"  [Ref.  7:p.  342]  .  For  the 
warfighter,  the  following  is  a  more  practical  description: 


Military  Doctrines  are  beliefs  or  teachings, 
which  have  been  reasoned  from  principles;  that 
is,  they  flow  from  principles  as  a  source.  They 
are  intended  to  be  general  guides  for  the 
application  of  mutually  accepted 
principles ...  and ...  a  practical  basis  for 
coordination  under  the  extremely  difficult 
conditions  governing  contact  between  hostile 
forces  [Ref.  8:p.  334]. 


In  order  for  Doctrine  in  the  military  to  be 
successful,  it  must  function  at  the  strategic,  operational, 
and  tactical  levels  of  warfare  [Ref.  9:p.  2] .  In  addition. 
Doctrine  must  function  for  each  individual  service  in  the 
armed  forces,  in  multi-service  or  joint  contexts,  and  in 
multi-national  or  combined  contexts. 

The  vital  role  of  Navy  Doctrine  contributes  to  the 
success  of  the  Navy's  decentralized  command  structure. 
Because  of  the  decentralized  command  structure  the  Navy  has 
the  ability  to  react  and  or  act  quickly.  Web-Enabled 
Doctrine  combines  an  old  concept  of  coordination  (Doctrine) 
with  new  information  technology.  It  seems  to  hold  the 
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promise,  when  fully  developed,  of  providing  Navy 
warfighters  the  ability  of  rapid  independent  action. 

The  Navy,  along  with  the  rest  of  DoD,  is  trying  to 
enact  a  Revolution  in  Military  Affairs  (RMA)  .  The  RMA 
revolves  around  information.  Information,  information 
processing,  and  communications  networks  are  at  the  core  of 
every  military  activity  [Ref.  3:p.  8]  .  Attaining 
Information  Superiority  implies  transforming  information 
into  superior  knowledge  and  decisions  [Ref.  3:p.  8] . 
Doctrine  is  central  to  this  effort. 

B.  NETWORK  CENTRIC  OPERATIONS  (NCO) 

In  order  to  understand  the  importance  of  WED,  we  first 
look  at  Network  Centric  Operations  (NCO) .  The  NCO  concept 
is  the  organizing  principle  for  developing  future  Navy 
forces  [Ref.  10  :p.  6]  .  This  transformation  into  the  Navy 
after  Next  requires  a  shift  from  platform-centric 
operations  (PCO)  to  NCO.  Figure  1  demonstrates  how  PCO 
center  on  individual  entities  that  make  up  a  larger  entity 
or  group,  but  lack  continuity  with  each  other.  NCO,  on  the 
other  hand,  contains  the  vital  continuity  lacking  in  PCO  as 
illustrated  in  Figure  2. 


Figure  1.  Platform-Centric  Operations  [Ref.  11] 
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Figure  2.  Network-Centric  Operations  [Ref.  11] 

This  shift  from  PCO  to  NCO  provides  a  vision  for  the 
Navy's  modernization  of  its  Fleet  and  dramatically  changes 
its  warfighting  capabilities  and  operations  [Ref.  12:p.33]. 

The  Navy' s  initiative  to  change  its  warfighting 
capability  is  driven  by  the  following:  joint,  effects- 
based  combat,  reliance  on  information  superiority,  and  the 
potential  for  adversaries  to  quickly  develop  technology  for 
asymmetric  use  against  U.S.  forces.  PCO  prevent  U.S.  Naval 
Forces  from  achieving  their  full  information  advantage  in  a 
timely  manner.  Such  an  information  advantage  is  imperative 
in  order  for  U.S.  Naval  Forces  to  counter  the  above- 
mentioned,  asymmetric  threats.  The  four  supporting 
concepts  of  NCO  that  are  considered  foundational  to 
ensuring  the  U.S.  Navy's  ability  to  achieve  information 
superiority  are:  gaining  information  and  knowledge 
advantage,  assured  access,  ef f ects-based  operations  (EBO) , 
and  forward  sea-based  forces. 

NCO  are  designed  to  effectively  pair  networking  and 
information  technology  with  EBO. 


It  will  exploit  state-of-the  art  information  and 
networking  technology  to  integrate  widely 
dispersed  human  decision  makers,  situational,  and 
targeting  sensors,  and  forces  and  weapons  into  a 
highly  adaptive  comprehensive  system  to  achieve 


9 


unprecedented  mission  effectiveness  [Ref.  13 :p. 

1]  . 

These  network  centric  capabilities  enable  a 
geographically  dispersed  naval  force  to  meet  its  desired 
objectives.  The  objectives  are  accomplished  through  NCO 
links  sensors,  shooters,  and  command-and-control  nodes. 
Figure  3  illustrates  these  links  and  nodes.  The  nodes  and 
links  of  the  network  enable  an  economy  of  force  through 
enhanced  speed  of  decision-making  and  rapid  self¬ 
synchronization.  With  greater  operational  demands  and  fewer 
assets,  economy  of  force  is  vital  in  today's  Navy,  making 
NCO  ideal. 

We  must  use  and  work  with  current  assets  and 
capabilities  while  continuing  to  improve  upon  them.  The  use 
of  new  capabilities  must  be  balanced  within  the  future  Navy 
while  complementing  our  legacy  forces  [Ref.  10:  p.  33]  . 
Developing  this  balance  while  moving  the  Navy  to  NCO 
requires  the  co-evolution  of  Doctrine,  organization, 
education,  and  technology  [Ref.  10:  p.  33]. 


Figure  3.  Links  and  Nodes  of  NCO  [Ref.  11] 
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WED  is  at  the  forefront  of  the  evolving  technology 
that  allows  the  Navy  to  accomplish  NCO.  WED  is  part  of  a 
dynamic  process  that  allows  NWDC  to  develop  or  continuously 
update  Navy  Doctrine  Publications  (NDPs) ,  Navy  Warfare 
Publications  (NWPs) ,  Navy  Tactics,  Techniques,  and 
Procedures  (NTTP) ,  and  the  Navy  Lessons  Learned  System 
(NLLS)  .  The  WED  as  a  dynamic  tool  is  able  to  collect  and 
distribute  vital  information  throughout  a  network.  Primary 
sources  of  information  for  the  WED  are  through 
collaborative  Eleet  dialogue,  Eleet  Battle  Experiments 
(FBE) ,  modeling,  and  simulation.  The  WED  is  designed  to 
ensure  the  rapid  development  of  joint-compatible  Doctrine 
and  operational  concepts.  By  embedding  naval  assets  within 
this  information  network  and  infrastructure,  adjustments 
and  adaptations  to  a  situation  within  a  battlespace  can 
occur  dynamically  as  they  emerge  [Ref.  13 :p.  2]  . 


C.  U.S.  NAVY  DOCTRINAL  PROCESS 

This  section  discusses  the  two  current  methods  of 
creating  Navy  Doctrine.  The  first  part  discusses  the  U.S. 
Navy  doctrinal  process  created  by  NWDC.  This  process  is 
referred  to  as  the  traditional  Doctrine  process.  The 
second  part  discusses  the  WED  process  introduced  in 
February  of  2000. 

1.  Traditional  Doctrine  Process 

The  process  of  developing  Doctrine  is  complex.  The 
Navy's  Doctrine  Process  is  a  decentralized  sequential 
process.  Taking  an  idea  or  concept  from  initial  thought  to 
a  finished  document  is  a  lengthy  process.  It  entails 
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planning  in  order  to  work.  Several  factors  and  processes 
work  together  as  well  as  oppose  one  another.  Figure  4 
illustrates  this  process. 

The  transition  from  idea  to  Doctrine  begins  with  a 
proposal.  Proposals  identify  a  deficiency  or  the  need  to 
update  current  Doctrine.  Theoretically,  any  person  can 
initiate  a  proposal,  but  the  Primary  Review  Authority  (PRA) 
usually  initiates  proposals.  The  PRA,  which  is  assigned  by 
NWDC,  is  a  command  with  expertise  in  the  proposal  area. 
PRAs  can  be  an  individual  command,  a  Warfare  Center  of 
Excellence,  or  from  the  office  of  the  Chief  of  Naval 
Operations  (OPNAV) .  Most  proposals  are  discussed  and 

endorsed  in  a  meeting  called  the  Navy  Doctrine  Working 
Party  (NDWP) [Ref.  14:p.  3-2] . 

While  this  thesis  focuses  on  the  overall  Doctrine 
process,  the  NDWP  needs  to  be  discussed  in  a  broad  sense. 
NDWP  is  a  bi-annual  forum  in  which  many  items  concerning 
current  and  emerging  Doctrine  and  tactics  are  discussed. 
The  NDWP  also  serves  to  consolidate  Fleet  inputs  and 
validate  proposals.  An  Executive  Steering  Committee  (ESC) 
heads  this  forum.  Its  members  include  representatives  from 
the  three  geographic  Commander  in  Chiefs  (CINCs) :  Commander 
in  Chief  Atlantic  Fleet  (CINCLANTFLT)  ,  Commander  in  Chief 
Pacific  Fleet  (CINCPACFLT) ,  and  Commander  in  Chief  U.S. 
Naval  Forces  Europe  (CINCUSNAVEUR) .  The  committee  also 
includes  representatives  from  Commander,  U.S.  Naval  Forces 
Central  Command  (COMUSNAVCENT) .  The  final  member  of  the 
committee  is  the  Facilitator,  Commander,  and  Navy  Warfare 
Development  Command.  These  members  make  up  the  voting  body 
that  determines  which  ideas  become  proposals  [Ref.  15] . 
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Membership  to  the  NDWP  is  not  limited  to  the  ESC  but 
includes  advisory  members  and  observers.  Advisory  members 
are  representatives  from  numbered  Fleet  Commands,  Type 
Commands,  Carrier  Groups,  Destroyer  Groups,  and  Amphibious 
Groups.  Advisory  members  are  officially  invited  and  are 
responsible  for  providing  recommendations  on  doctrinal 
issues  and  articulating  operational  concerns.  Observers 
are  the  other  Navy  organizations  that  have  requested  to 
attend  the  round-table  [Ref.  15]. 

NWDC  is  responsible  for  all  Doctrine  affecting  the 
Navy.  They  validate  all  proposals  or  program  directives 
(PD)  issued  by  OPNAV  or  a  PRA.  Validation  is  necessary  to 
determine  the  need  for  new  Doctrine  or  an  existing 
insufficiency  in  current  Doctrine.  Proposals  have  to  be 
well  articulated  and  in  a  specific  format  to  receive 
approval.  Those  proposals  and  or  PDs  considered  inadequate 
are  returned  for  further  revision  or  terminated  [Ref.  14 :p. 
3-2]  . 

NWDC  endorses  the  proposal  and  then  issues  a  Program 
Directive  (PD)  .  A  PD  sent  by  formal  Navy  message  provides 
the  preliminary  documentation  needed  for  planning  and 
resource  allocation  in  the  development  or  revision  of 
Doctrine.  The  PD  identifies  the  scope  of  the  publication 
to  be  produced,  the  audience  and  other  publications 
affected  by  the  Doctrine  project,  milestones,  and 
administrative  items.  It  also  designates  the  primary 
actors  assigned  to  the  Doctrine  development  task.  The  main 
actors  are  the  PRA,  Coordinating  Review  Authority  (CRA) , 
Technical  Cognizant  Office  (TCO) ,  and  NWDC  Action  Officer 
[Ref.  14:p.  3-3]. 
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The  PRA  is  responsible  for  all  doctrinal  publications 
assigned  to  them  from  "cradle  to  grave."  This  includes 
developing,  coordinating,  reviewing,  and  maintaining  the 
publications.  The  CRA  is  responsible  to  the  PRA  and 
assists  the  PRA  in  performing  its  assigned  tasks.  The  CRA 
assists  in  developing  the  draft,  performing  necessary 
research,  and  providing  comments  where  appropriate.  The 
CRA  is  the  liaison  between  the  Fleet  and  the  PRA.  The  TCO 
is  responsible  for  money  and  resources.  The  TCO  ensures 
that  appropriate  funds,  technical  support,  and  manpower  are 
programmed  and  available.  The  NWDC  Action  Officer  is  the 
liaison  between  the  PRA  and  NWDC  [Ref.  14 :p.  2-4] . 

Composing  the  draft  is  the  next  stage  in  Doctrine 
development.  Before  actual  composition,  the  PRA  along  with 
the  CRA  designate  Contributing  Commands  (CCs)  [Ref.  14  :p. 
3-3]  .  CCs  provide  technical  and  tactical  input  for  the 
publication.  The  PRA  and  CRA  determine  the  CCs 
responsibilities  [Ref.  14:p.  2-7]. 

The  PRA,  together  with  the  CRA,  TCO,  and  CC,  develops 
an  outline  from  information  contained  in  the  proposal,  PD, 
Navy  Lessons  Learned  Library  (NLL) ,  After  Action  Reports, 
operation  tests.  Fleet  Battle  Experiments  (FBE)  and  various 
available  sources.  NWDC  receives  the  outline  for  approval. 
At  this  point,  the  proposed  document  is  at  its  most 
vulnerable.  NWDC  can  terminate  the  entire  project  if  it 
finds  that  the  proposed  Doctrine  is  not  necessary  or  return 
the  outline  to  the  PRA  for  further  development.  NWDC  also 
has  the  option  of  sending  the  project  back  to  the  proposal 
stage  for  re-evaluation  and  thus  starting  the  process  over 
again . 
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Once  the  outline  has  been  approved,  the  PRA,  in  order 
to  minimize  delays,  has  to  establish  a  date  after  which  no 
new  information  will  be  accepted,  with  the  exception  of 
safety  related  findings  or  critical  requirements  [Ref. 
14 :p.  3-3] . 

From  the  outline,  the  PRA  creates  a  draft.  This  draft 
is  sent  to  the  CRA,  CC  and  NWDC,  as  it  is  developed.  The 
CRA  and  CC  are  required  to  review  and  make  comments  as 
necessary.  The  PRA  and  CRA  may  restrict  the  CC  to  advisory 
comments  only  if  they  see  fit.  The  PRA  resolves  comments 
by  the  CRAs  and  CCs .  If  the  PRA  cannot  resolve  the 
comments,  then  the  NWDC  becomes  the  adjudicating  authority 
on  Navy  Warfare  Publications.  For  publications  other  than 
NWPs,  resolution  could  be  an  endless  loop  between  the  CRA 
and  PRA  [Ref.  14:p.  3-4]. 

Once  the  draft  has  been  resolved,  NWDC  conducts  a 
final  review  of  the  document.  NWDC  endorses  and  forwards 
the  document  to  the  Technical  Publications  branch  for 
distribution  [Ref.  14:p.  3-5]. 

This  process  is  repeated  for  revisions,  changes,  and 
reviews.  Usually  reviews  are  required  at  two  to  three  year 
intervals  depending  on  the  publication  [Ref.  14 :p.  3-6]  . 
Revisions  occur  at  intervals  no  greater  than  ten  years 
[Ref.  14 :p.  3-2] .  There  is  no  established  timeline  for  the 
doctrinal  process;  however,  this  process  may  take  up  to 
eighteen  months.  Although  timeliness  is  necessary,  quality 
content  is  a  more  highly  desired  outcome. 
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Figure  5  represents  the  fundamental  Doctrine 
development  process.  Decision  points  are  removed  because, 
for  Doctrine  to  be  completed,  all  decisions  require  a 
"yes."  Once  a  proposal  is  made,  a  PD  is  issued.  The  PD 
identifies  the  project  leader  and  other  supporting  project 
members.  Research  and  analysis  of  the  PD  and  proposal 
begin  after  the  work  group  is  identified.  An  outline  is 
then  created,  and  a  draft  is  developed.  The  members  of  the 
project  team  review  and  scrutinize  the  draft.  Project 
leaders  make  resolutions  to  the  draft  after  the  review 
process.  The  resolved  document  is  forwarded  for  further 
review  and  revision.  This  process  produces  the  final 
Doctrine  document.  The  approved  document  is  sent  to 
publishing  for  distribution  to  the  Fleet.  After  a 

specified  amount  of  time,  the  document  is  reviewed,  and  the 
process  begins  again. 


Figure  5.  Fundamental  Doctrine  Development  Process 
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2. 


Web-Enabled  Doctrine  (WED)  Process 


Web-Enabled  Doctrine  (WED)  is  a  means  to  provide 
operationally  relevant  Doctrine  to  the  Fleet.  WED  enables 
the  Fleet  to  participate  in  the  development  of  Doctrine  in 
ways  other  than  testing.  Embracing  the  concept  of  WED 
enables  the  Navy  to  accelerate  its  transformation  to  NCO. 
The  WED  has  been  online  for  over  a  year.  It  is  a  dynamic 
process  meant  to  capture,  develop,  and  validate  doctrinal 
insights  from  proven  at-sea  experience.  WED  requires  the 
experience  of  the  sailor  on  the  deck  plates  who 
incorporates  Doctrine  into  their  daily  routines. 

The  WED  process  parallels  the  traditional  process 
previously  discussed.  It  is  initiated  by  a  Navy  major 
command.  Warfare  Center  of  Excellence,  or  senior  leadership 
board  [Ref.  2:p.  73]  that  presents  a  proposal  to  the  Navy 

Doctrine  Working  Party  (NDWP) . 

Figure  6  is  a  screen  shot  of  the  current  WED  comment 
entry  site.  This  form,  much  like  a  network  trouble  call 
form,  is  designed  to  accept  input  from  the  fleet.  This 
first  step  towards  collaborating  in  a  distributive 
environment  is  currently  cumbersome  and  difficult  to  use. 
The  sailor  who  operates  the  equipment  still  has  to  get  his 
idea  to  the  initiating  entities  discussed  above.  The 
comment  that  sent  via  the  web  site  becomes  an  internal 
working  memorandum  that  is  visible  to  those  who  have 
access.  The  progression  of  the  comment  is  not  as  readily 
visible,  and,  thus  the  initiator  is  left  out  of  the  rest  of 
the  process. 
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Figure  6.  WED  Screen  Shot  [Ref.  17] 

WED  is  designed  to  enable  the  Fleet  to  enter  into  the 
development  of  Doctrine  rather  than  restricting 
participants  to  senior  level  commands  and  leadership 
symposiums.  Fleet  involvement  in  the  development  process 
allows  for  engagement  at  the  lowest  echelons.  The  Fleet 
has  first  hand  knowledge  of  its  day-to-day  operations.  It 
is  familiar  with  the  employment  of  its  systems  and  assets. 
WED  is  designed  to  enable  sailors,  whose  lives  revolve 
around  their  ships  and  their  operations,  to  infuse 
innovative  insights  and  practical  experience  into  Doctrine. 

Another  aspect  of  WED  is  to  reduce  the  time  required 
for  Doctrine  development.  The  NWDC  currently  takes  months 
or  years  to  develop  and  produce  Doctrine.  WED  makes 
possible  a  real  time,  collaborative,  responsive  system  as 
opposed  to  waiting  for  Fleet  or  command  input  to  be 
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processed,  reevaluated,  and  disseminated  for  more 
assessment.  By  reducing  the  amount  of  time  in  the 
development  process,  it  increases  the  likelihood  the  Fleet 
is  in  possession  of  the  most  relevant  and  current  Doctrine 
at  its  disposal. 

RMA  requires  a  transformation  of  the  U.S.  military's 
"scattergun  approach"  to  combat  Doctrine,  strategy,  and 
tactics  [Ref.  6:p.  23]  .  The  envisioned  WED  is  the  enabler 
that  allows  the  Fleet  active  participation  in  the  entire 
development  process  from  conception  to  the  final  document 
known  as  Doctrine. 
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Ill .  COMMERCIAL  OFF  THE  SHELF  AND  DISTRIBUTIVE 
COLLABORATIVE  TECHNOLOGY 


A.  COMMERCIAL  OFF  THE  SHELF  (COTS) 

Traditionally,  purchases  by  the  DoD  were  managed  by  a 
set  of  Federal  Specifications  (FEDSPECS)  and  Military 
Specifications  (MILSPECS)  .  EEDSPECS  are  standards  that 
developers  use  to  sell  goods  to  the  government.  MILSPECS 
are  the  approval  criteria  for  purchases  for  military  use. 
As  the  government  used  these  specifications  as  purchasing 
criteria,  it  resulted  in  increased  costs  and  delays  in 
access  to  new  technology  [Ref.  19] . 

As  the  progression  of  the  RMA  continues,  the  defense 
environment  continues  to  change  alongside  it.  For  nearly 
200  years,  the  tools  and  tactics  of  how  we  fight  have 
evolved  with  military  technologies  [Ref.  18  :p.  1]  .  In  the 

past,  militaries  have  been  the  creators  and  keepers  of  new 
technologies.  During  the  1970s,  DoD  COTS  use  was  minimal. 
Because  the  commercial  market  sold  items  at  a  cheaper 
price,  COTS  products  were  used  solely  to  save  money  in  the 
1980s.  By  1990,  money  and  time  became  huge  factors  in 
acquiring  COTS  products.  Developing  and  fielding  new 

systems  became  expensive  and  consumed  large  amounts  of 

time.  Today  the  developmental  role  has  shifted  to  the 
common  marketplace.  The  RMA  is  characterized  by  the  co¬ 
evolution  of  economics,  information  technology,  and 

business  processes  and  organizations  [Ref.  18:p.  2]. 


The 
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capabilities  of  any  government  research  and  development 


(R&D)  program  [Ref. 20]  .  The  fact  is  that  our  traditional 
processes  and  strategies  for  acquiring,  developing, 
fielding,  and  supporting  weapons  and  business  systems  must 
be  adapted  to  the  world  we  live  in  [Ref.  21] . 

The  beauty  of  COTS  products  is  their  applicability  to 
a  spectrum  of  systems.  COTS  have  evolved  to  encompass  a 
multitude  of  uses,  especially  within  the  area  of 
information  technology.  They  range  from  geographic 
information  systems  for  command  and  control,  product  data 
management  for  sustainment  support,  and  financial  packages 
for  comptrollers.  The  preference  for  COTS  usage  is 
demonstrated  by  DoD  supporting  and  Congress  passing  the 
Federal  Acquisition  Streamlining  Act  (FASA)  of  1994, 
Section  8104  [Ref.  22 :p.  1] .  COTS,  by  definition,  are  items 
customarily  used  for  non-government  purposes.  COTS  is 
further  defined  by  DoD  Directive  5000. 2R  as: 

Any  item  that  (1)  has  been  sold,  leased,  or 
licensed  to  the  general  public;  or  (2)  has  been 
offered  for  sale,  lease,  or  license  to  the 
general  public;  or  any  item  that  evolved  through 
advances  in  technology  or  performance  and  that  is 
not  yet  available  in  the  marketplace,  but  will  be 
available  in  the  commercial  marketplace  in  time 
to  satisfy  the  delivery  requirements  under  a 
Government  solicitation  [Ref.  22:p.  2]. 


The  definition  also  includes  services  in  support  of  a 
commercial  item. 

Because  of  shrinking  budgets,  COTS  is  ideal  for  many 
government  agencies.  Typically,  the  Navy  or  DoD  would 
develop  a  system  from  cradle  to  grave.  Developing  a  system 
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from  cradle  to  grave  includes  identifying  requirements, 
identifying,  designing,  and  detailing  architecture, 
subsystems  and  modules.  Integrating  the  system  and 
subsystem  occurs  after  coding  and  debugging.  Nevertheless, 
with  COTS,  there  is  a  fundamental  change  from  development 
to  composition  as  shown  in  Figure  7.  COTS  allow  an 
organization  to  construct  a  system  from  building  blocks. 


The  Fundamental  Change 

Traditional  Approach 

Required  COTS  Approach 

(W^erfall  Development) 

Sjfstem 

System 

Ccntext 

Ccntext 

Architect  Lre 

&  Design 

MarVietplace  Architecture 

hnplemenrtation 

&  Design 

Sec/uential  consideration 

Sm  ultaneous  cons  id  er  atic  n 

Figure  7.  Fundamental  Change  to  COTS  [Ref.  23] 

The  fundamental  change  to  COTS  involves  a  dynamic 
interaction  between  the  system  context,  marketplace,  and 
the  architecture  and  design.  Market  mechanisms  allow  for 
simultaneous  consideration  as  opposed  to  the  traditional 
sequential  approach  [Ref.  24:p.  5].  Because  the 

traditional  approach  is  sequential,  system  development  is 
dependent  on  the  success  of  the  previous  stage,  which 
equates  to  consuming  time.  At  the  conclusion  of  this 
process,  one  hopes  that  the  system  satisfies  the  intent  of 
the  design.  If  the  system  does  not  satisfy  its  intent, 
money  and  time  are  wasted  and  the  development  of  a  new 
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system  must  begin.  However,  maximizing  COTS  can  save  time 
and  money.  COTS  adapts  requirements  to  the  capabilities 
available  in  the  marketplace  rather  than  adapting 
commercial  capabilities  to  DoD  requirements  [Ref.  24:p.  5]. 

The  primary  approach  used  in  the  acquisition  of 
command  and  control  and  information  systems  is  the  buy- 
and-adapt  Model  [Ref.  25 :p.  3] .  As  the  model's  name 
implies,  the  commercial  system  that  meets  most  of  the 
requirements  is  purchased.  This  system  then  is  tailored  to 
meet  or  overcome  the  deficiencies  of  the  acquisition 
agency's  requirements.  This  study  uses  a  buy-and-adapt 
approach  to  COTS . 

1 .  The  Burden  of  COTS 

A  major  disadvantage  with  COTS  products  is  that  they 
entail  a  set  of  trade-offs.  When  the  Navy  develops  its  own 
system,  plans  are  in  place  for  planned  maintenance,  parts 
replacements,  and  system  upgrades.  Specific  requirements 
must  be  sufficiently  flexible  to  accommodate  a  variety  of 
available  commercial  products  and  their  associated 
fluctuations  over  time  [Ref.  26:p.  3]. 

If  an  organization  cannot  remain  flexible  when  using 
COTS,  then  COTS  becomes  a  burden  within  their  system. 
Flexibility  is  mandatory  because  the  inherent  problem  of 
continuous  upgrading  exists  with  COTS  usage.  The 
marketplace  coordinates  this  need  for  continuous  upgrading. 
Competition  among  COTS  developers  remains  intense.  Each 
developer  strives  to  be  the  first  to  develop  a  faster  more 
innovative  product  that  is  easily  adaptable  within  a  system 
of  systems. 


Integration  can  be  accomplished  via  this  same  market 
logic.  However,  there  will  be  occasions  when  the  use  of 
COTS,  especially  software,  inevitably  leads  to  integration 
concerns.  One  factor  that  comes  into  play  when  integration 
begins  is  compatibility.  COTS  upgrades  may  no  longer  be 
compatible.  This  incompatibility  creates  a  chain  reaction 
that  has  the  potential  to  obstruct  the  entire  system.  For 
the  DoD  this  is  a  critical  concern.  Blocking  or  stalling  a 
Command  and  Control  (C2)  system  while  compatibility  is 
being  pursued  is  unacceptable.  Foreseeing  such  integration 
problems  requires  strong  acquisition  and  management 
programs  and  practices. 

2 .  The  Benefits  of  COTS 

COTS  products  offer  several  benefits.  They  offer  cost 
savings,  greater  choice,  the  newest  and  most  innovative 
features,  increased  convenience  and  accessibility,  bulk 
purchasing,  and  decreased  redundancy  and  duplication  [Ref. 
19]  .  However,  in  order  to  reap  the  benefits  of  COTS,  the 
organization  has  to  be  willing  to  accept  the  existing 
capabilities  and  limitations  of  the  software.  Failure  to 
accept  these  terms  results  in  COTS  becoming  a  burden  rather 
than  a  benefit.  When  considering  COTS,  there  must  be  a 
complete  understanding  of  the  technology  involved  within 
the  system. 

Increased  convenience  relates  directly  to  immediate 
availability.  COTS  products  can  be  viewed  and  tested 
immediately  [Ref.  27 :p.  2] .  Because  COTS  is  readily 
available,  it  reduces  the  time  required  to  implement  a 
solution  [Ref.  27 :p.  1] .  Solutions  that  are  implemented 
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rapidly  reduce  project  risk.  There  are  no  longer  lengthy 
waiting  periods  or  expensive  expenditures  before  the  final 
system  can  be  viewed  and  tested  [Ref.  27 :p.  1] . 

Ready  availability  applies  only  to  the  COTS  product 
itself.  This  benefit  is  available  only  to  COTS  products 

that  are  completely  system  compatible.  If  such 

compatibility  is  not  reached,  the  result  is  delayed 
benefits.  Nevertheless,  once  compatibility  is  achieved, 
the  benefits  of  rapid  technological  advancement  can  be 
realized. 

COTS  are  innovative  in  nature.  The  designers  and 
developers  of  COTS  concentrate  on  producing  a  product  that 
is  one  step  ahead  of  its  competitors.  This  provides  the 
benefit  of  greater  choice  and  a  broad  industrial  base.  The 
ability  to  choose,  as  opposed  to  developing,  the 

appropriate  component  saves  time  and  money.  Again  choosing 
the  appropriate  COTS  component  for  a  system  takes 
appropriate  program  management  competencies  to  ensure  that 
proper  integration  is  attainable;  otherwise,  the  benefits 
may  not  be  realized. 

Cost  savings  is  the  benefit  most  touted  by  COTS 

developers.  Together  with  bulk  purchasing,  COTS  offers  a 

cheaper  alternative  to  rapidly  deploying  the  most  innovated 
system  components.  It  is  cost-effective  for  DoD  to  have 
access  to  this  state-of-the-art  technology. 

B.  DISTRIBUTIVE  COLLABORATIVE  TECHNOLOGY  (DCT) 

Distributive  Collaborative  Technology  (DCT)  is  one  of 

the  many  refrains  of  the  information  revolution.  To 

clearly  understand  DCT,  a  definition  of  distributive  and 
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collaborative  is  needed.  Distributive  is  defined  in  terms 
of  the  dispersed  nature  of  networks  and  the  people  who  use 
them,  while  collaborative  is  defined  as  working  together 
and  in  cooperation.  DCTs  are  products  that  synchronously 

or  asynchronously  enable  many  to  many,  one  to  many,  and 
many  to  one  communications  [Ref.  28  :p.  1]  .  These  tools 

enable  users  to  manage  knowledge  in  a  virtual  domain 
through  virtual  collaboration. 

Collaboration  tools  increase  productivity  by 
simplifying  decision  cycles  in  the  Observe,  Orient,  Decide, 
and  Act  (OODA)  Loop.  Collaborative  technology  provides 
users  with  the  ability  to  share  information  and  make 
decisions  in  a  near  real  time  environment.  Distances 
between  users  are  not  a  factor  [Ref.  28 :p.  1] .  The 

collaborative  environment  also  fosters  innovation  through 
shared  ideas  [Ref.  28:p.  4]. 

Increasing  numbers  of  networks  and  the  startling 
growth  of  the  Internet  are  the  technical  drivers  of  DCT . 
Changes  in  our  culture  and  the  desire  for  increasing 
efficiency  are  pushing  collaboration  to  the  forefront  of 
business  practices.  Large  numbers  of  people  are  choosing 
to  work  at  home  in  order  to  enjoy  more  leisure  time  or 
increase  their  work  capacity.  There  is  a  robust  volume  of 
information.  Many  large  corporations  are  redefining  their 
business  practices  to  incorporate  DCTs  in  order  to  make 
informative,  rapid  decisions  [Ref.  28:p.  10]. 

DCTs  not  only  affect  business  corporations,  they  also 
affect  other  facets  of  life.  The  most  common  forms  of  DCTs 
are  email  and  calendar  software  packages  such  as  Microsoft 
Outlook.  The  U.S.  military  uses  another  collaborative 
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tool,  the  Global  Command  and  Control  System  (GCCS)  [Ref. 
28  :p.  1]  .  This  system  allows  military  units  to  observe  the 
entire  battlespace  and  make  inputs  visible  to  all  system 
users . 

C.  COTS  DCT  PRODUCT  REVIEW 

Zaplet  Inc.  developed  the  Zaplet  Appmail  Suite™  as  a 
server-based  DCT.  This  DCT  is  the  exemplar  or  model  for 
this  study,  because  it  closely  resembles  the  ideas  of  the 
envisioned  WED.  The  Zaplet  Appmail  Suite™  provides 

technologies  that  allow  people  to  collaborate  and  share 
information  through  the  application  of  Appmail  [Ref.  29]  . 
The  Appmail  application  provides  a  window  to  the  server. 
It  allows  the  user  accessibility  to  the  most  current 
information . 

The  design  of  the  Appmail  application  allows  any  user 
to  initiate  it.  The  project  lead  uses  tools  and  building 
blocks  provided  by  Zaplet  to  create  the  Appmail.  The 
project  lead  initiates  and  develops  the  Appmail  in  a  way 
that  best  suits  the  project  [Ref.  30:p.  5]  .  Figure  8 

displays  the  Appmail  structure. 
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Structure  of  a  Zaplet  appmail  message 


Figure  8.  Appmail  Message  [Ref.  30 :p.  3] 

Most  employees  spend  a  substantial  amount  of  time 
checking  their  email.  Appmail  takes  advantage  of  this 
phenomenon  and  uses  email  as  a  launch  platform  for  its  DCT . 
Most  organizations  use  email  programs  such  as  Microsoft 
Outlook  and  Netscape  Communicator.  Appmail  is  applicable 
to  these  major  email  programs  [Ref.  30  p.l6] .  Acting  on 
the  principles  of  email,  the  Appmail  is  sent  and  delivered 
to  the  inbox  of  the  addressee.  To  display  the  latest 
collaboration  requires  the  addressee  to  open  the  Appmail. 
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The  Appmail  automatically  organizes,  summarizes,  and 
processes  the  contributions  of  each  recipient  and  is 
continuously  updated  to  reflect  the  latest  input  [Ref. 
30:p.  4].  The  project  lead  sends  notification  messages 
through  email  to  its  group  to  review,  collaborate,  and  take 
action.  Because  pertinent  information  is  located  within 
the  Appmail,  members  can  render  a  decision,  collaborate,  or 
formulate  a  response.  This  saves  team  members  time.  They 
no  longer  have  to  process  and  read  separate  emails  in  a 
threaded  discussion.  Instead,  their  information  is  located 
in  one  email  message. 

Appmail  is  constructed  by  using  a  core  of  building 
blocks  from  the  Zaplet  Appmail  Builder™.  Table  1 
illustrates  the  building  block  library. 
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Discussion:  Iniiiaie  a  discussion  and  view  ever)’ones  commenis  in  one  place.  Use 
10  brainstonn  ideas  and  gather  feedback. 


Poll:  Gather  opinions  and  feedback  on  a  specific  question.  See  voters’  comrnents 
and  a  chart  of  the  results. 


Interactive  Web  Page:  Interact  with  web-based  content,  application,  or  service 
within  the  apptnail. 

File  Sharing:  Di.stribute  files  for  review  and  collaboration.  A  version  control  option 
allows  participants  to  refer  back  to  previous  file  versions. 

Inline  Document:  View  an  uploaded  document  inline  within  the  appmail,  elimi¬ 
nating  the  need  to  launch  a  separate  application. 


Table:  Create  a  table  of  information  that  a  group  can  share  and  update.  Useful  for 
shared  management  tasks  such  as  collecting  data  and  tracking  action  items. 


Ratings:  Gather  opinions  on  up  to  50  questions.  Recipients  respond  to  each  ques¬ 
tion  using  a  scale  defined  by  the  author  and  can  see  a  chart  of  the  results. 
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Survey:  Gather  c|uantitative  or  qualitative  feedback  from  recipients  across  multi¬ 
ple  types  of  questions.  Survey  initiator  can  view'  dynamically  tabulated  results  at 
any  time  and  easily  export  merged  data. 

Approval  List:  Request  approval  for  any  file,  process,  or  issue.  Participants  can 
either  approve  or  disapprove  and  share  comments. 


Schedule:  Arrange  a  meeting  or  event  by  specifying  dates  and  times  for  group 
scheduling.  Export  agreed  meeting  time  to  desktop  calendar  application. 


Image:  Display  an  image  for  sharing  and  review. 


Image  Gallery:  Display  up  to  36  images  for  sharing  and  review  within  the  appmail. 

H  jL  i.  X 


Invitation:  Invite  colleagues  to  meetings  and  other  events,  display  event  details, 
and  collect  RSVPs  and  comments  from  invitees. 


Information  Fields:  Build  forms  using  fields  such  as  name,  date,  and  location, 


Table  1.  Zaplet™  Building  Block  Library  [Ref.  30 :p.  6] 
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Enabling  specific  functions,  these  building  blocks 
contain  user  interface,  data  elements  and  processing 
capability  [Ref.  30:  p.  5] .  These  building  blocks  form  the 
collaborative  page.  The  collaborative  page  can  be 
transformed  into  multiple  pages.  The  project  lead  sets  the 
pages  in  precedence  to  ensure  that  the  proper  process 
occurs.  The  project  lead  can  edit,  add,  or  delete  the 
collaborative  page  even  after  the  Appmail  is  sent. 

An  organization  can  save  the  Appmail  application  it 
built  after  its  use.  The  application  is  saved  and  stored 
in  a  personal  or  shared  folder,  which  is  accessible  to 
members  within  the  organization.  This  saves  time  and 
diverts  effort  towards  adjusting  the  blocks  to  accommodate 
a  new  task. 

The  Zaplet  Appmail  Starter  Set™  is  a  collection  of 
general-purpose  applications.  These  applications  address 
common  business  tasks  and  activities  that  occur  among 
project  teams  and  departments,  such  as  coordinating 
meetings,  sharing  files,  or  gathering  group  input  to 
formulate  a  decision  [Ref.  30:p.  8]. 

The  general-purpose  applications  are  divided  into 
three  categories.  They  are  Collect  and  Structure  Feedback, 
Share  Information,  and  Make  Group  Decisions.  Collect  and 
Structure  Feedback  consist  of  three  subcategories: 
Discussion,  Table,  and  Survey.  The  attributes  of 
Discussion  include  the  ability  to  rapidly  solicit  feedback 
and  collect  opinions  viewed  in  a  single  location.  The 
Table  collects  and  structures  common  data.  Survey  gathers 
internal  and  external  feedback  and  can  be  done  with  or 
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without  anonymity.  Respondents  have  the  ability  to  change 
their  vote  or  suggestion. 

The  Share  Information  category  consists  of  the 
following  subcategories:  File  Sharing,  Inline  Document, 
and  Interactive  Web  Page.  File  Sharing  is  a  means  of 
distributing  information  to  team  members.  Inline  Document 
allows  users  to  place  a  document  directly  within  the 
Appmail,  with  full  scrolling  capabilities  [Ref.  30:p.  9]. 
The  Interactive  Web  Page  is  an  embedded  web  page  with  full 
navigational  capabilities  within  the  Appmail  (as  opposed  to 
having  a  link)  [Ref.  30 :p.  9] .  Figure  9  displays  the 
embedded  web  page . 

The  Make  Group  Decisions  category  includes  the 
application  of  Poll,  File  Approval,  and  Ratings.  The 
Poll  application  collects  votes  and  comments  in  order  to 
gain  a  census  among  the  participants.  Appmail  displays  the 
votes  and  comments.  These  results  can  be  revealed  at  a 
specified  time.  The  user  is  able  to  vote  for  more  than  one 
option,  vote  anonymously,  or  construct  a  secret  ballot 
[Ref.  30 :p  10] .  The  File  Approval  application  brings 
people  who  are  geographically  dispersed  together  through  a 
single  Appmail  in  order  to  make  an  approval.  It  reduces 
the  amount  of  time  to  gather  relevant  information  for  a 
presentation  to  the  group  through  its  design.  The  Ratings 
application  is  based  on  the  author's  rating  scale.  It 
presents  preferences  and  opinions  of  the  group. 
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Interactive  Web  Page  appmail  delivered  to  email  inbox 


Figure 

9. 

Interactive  Web  Page 

[Ref.  30 

:p.  9] 
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applications 

[Ref.  30  :p.  13]  .  The  Portal  stores  both  sent  and  received 
Appmails  in  the  user' s  personal  archive 

The  Zaplet  Appmail  Server™  provides  the  infrastructure 
needed  to  use,  develop,  and  deploy  Appmail  [Ref.  30 :p.  15]  . 
The  Appmail  Server  contains  platform  services  such  as 
security,  access  control,  notification,  synchronization  of 
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Appmail  for  offline  use,  and  integration  with  corporate 
directories.  These  services  enhance  the  value  of  Appmail 
to  end  users,  while  meeting  enterprise  requirements  for 
broad  deployment  [Ref.  30:p.  15]. 

Appmail 's  security  platform  is  a  combination  of 
existing  security  products  and  a  unique  security  feature. 
The  security  framework  is  based  on  the  standards  of 
industry-leading  security  solutions  already  in  place  at  the 
system  level.  User  authentication  and  encryption  are  used 
to  ensure  the  privacy  of  the  user  and  sensitive  data.  The 
Server  can  be  integrated  with  leading  email  and  network 
systems  to  provide  the  convenience  of  a  single  sign-on  to 
access  the  Appmail  Suite  [Ref.  30 :p.  15]  .  This  allows  the 
Appmail  Suite  to  provide  seamless  integration  with  the 
security  environment  and  policies  of  the  enterprise  [Ref. 
30:  p.  15] 

The  Zaplet  Appmail  Server™  allows  secure  collaboration 
through  unique  security  features  and  can  be  coupled  with 
other,  existing  security  products.  The  Appmail  and  most  of 
its  content  is  located  within  the  Appmail  Server.  Because 
all  the  applications  for  Appmail  reside  in  the  server,  it 
prevents  harmful  content  from  being  delivered  to  the  client 
system  of  a  recipient.  The  security  platform  offers  the 
ability  to  restrict  forwarding  or  restrict  forwarding 
beyond  the  original  recipient  list.  Appmail  is  maintained 
on  a  central  server.  It  allows  the  information  technology 
staff  to  have  more  control  over  attached  files. 

Access  control  is  administered  through  Zaplet  Portal™. 
The  portal  contains  the  list  of  registered  users  within  the 
Suite.  The  author  of  the  Appmail  determines  the  list  of 


35 


users  who  are  able  to  view  the  Appmail,  or  the  author  may 
limit  the  visibility  of  pages  or  portions  of  the  Appmail  to 
certain  users.  Through  the  security  framework,  the  Appmail 
Server  can  leverage  existing  access  control  databases 
within  the  enterprise  to  determine  access  privileges  [Ref. 
30 : p .  15 ]  . 

Notifications  notify  the  user  of  changes  to  an  Appmail 
or  if  the  user's  attention  is  required.  Notifications  do 
not  necessary  apply  to  the  entire  Appmail.  Notifications 
can  be  directed  to  a  specific  portion  of  the  Appmail.  For 
example,  in  an  Appmail  with  multiple  tasks  and  discussions, 
the  user  may  only  wish  to  be  notified  when  a  schedule  is 
updated,  but  not  when  comments  are  received  [Ref.  30  :p. 
15]  . 

Appmail  demonstrates  its  dynamic  ability  by 
synchronizing  Appmail  for  offline  use.  By  synchronizing 
Appmail  with  the  Zaplet  Plug-in,  a  client-side  software 
plug-in  for  Microsoft  Outlook©  2000,  the  Appmail  Server 
allows  users  to  interact  with  any  Appmail  when  offline 
[Ref.  30:p.  16]. 

Zaplet ' s  DOT  is  simple  and  versatile.  It  is  a 
collaborative  application  designed  specifically  for  users 
of  email  in  mind.  The  application  uses  email  fundamentals 
as  a  launch  platform,  which  is  accessible  through  the  users 
email  inbox  or  web  browser  [Ref.  Zaplet  Meeting] .  This  DOT 
contains  applications  that  can  enhance  the  WED  process. 
Chapter  IV  applies  the  Zaplet  DCT  to  the  WED  process.  The 
chapter  uses  VITEPROJECT  Manager  as  the  model  to  determine 
the  effectiveness  and  efficiency  of  applying  a  COTS  DCT  to 
the  WED  process. 
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IV.  COTS  DCT  WITHIN  THE  NAVY  DOCTRINAL  PROCESS 


A.  APPLICABILITY  OF  COTS  DCT  WITHIN  THE  NAVY 

This  section  of  Chapter  IV  discusses  the  applicability 
of  Zaplet  Appmail  to  the  Navy  Doctrinal  process.  The 
Doctrine  development  process  is  part  of  the  Navy' s  legacy 
system.  Changes  to  that  legacy  system  often  are  met  with 
resistance.  Adapting  to  a  new  system  is  difficult.  The 
user's  comfort  and  confidence  level  may  be  decreased. 
Nevertheless,  the  fundamental  shift  to  NCO  forces  legacy 
systems  to  adapt  to  the  fast  pace  of  evolving  technologies. 
Zaplet' s  Appmail  gives  the  Navy  the  ability  to  transform 
its  Doctrine  development  process  for  the  21®^  century.  The 
transformation  is  transparent.  The  launch  platform  for 
Appmail  is  email.  The  familiarity  with  email  makes  the 
applicability  of  Appmail  to  the  Doctrine  process  easy. 

Appmail  uses  applications  and  programs  currently  used 
within  the  Navy  organization.  The  Navy  is  an  asynchronous 
organization  due  to  the  dispersal  of  its  ships. 
Technology,  such  as  VTC,  has  allowed  Naval  units  to 
overcome  long  distances  for  face-to-face  collaboration. 
However,  there  are  trade  offs  associated  with  VTCs .  VTC 
requires  a  large  amount  of  bandwidth.  Smaller  ships  such 
as  cruisers  and  destroyers  lack  the  capability  to  support 
VTC  due  to  bandwidth  constraints.  Although  VTC  can 
overcome  distance,  it  has  a  drawback  associated  with  time. 
Key  personnel  located  throughout  various  time  zones  hinder 
collaboration  through  VTC.  Personnel  unable  to  participate 
in  VTCs  do  not  obtain  the  disclosed  information  delivered 
during  the  session.  Zaplet' s  Appmail  replaces  the 
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requirement  of  attendance  at  meetings.  Through  Appmail's 
applications,  personnel  are  notified  through  their  email 
accounts  of  an  updated  information  exchange.  By  accessing 
their  email,  users  can  display  near  real  time  information. 
The  asynchronous  characteristic  of  Appmail  makes  it  an 
ideal  collaborative  tool  for  the  Navy.  NWDC  desires  a 
dynamically  developed  process  for  Doctrine.  WED  is  the 
first  step  to  achieving  the  goal  of  dynamic  Doctrine. 
Figure  9  applies  Zaplet  to  the  Doctrine  development 
process . 

The  next  section  describes  the  current  Doctrine 
development  process  in  four  phases  using  Zaplet  Appmail. 
During  these  phases,  activities  occur  concurrently  vice 
sequentially . 


B.  APPLYING  COTS  DCT  TO  THE  DOCTRINE  PROCESS 

Phase  One  is  Requirement  Collection.  In  this  phase, 
there  are  three  activities:  proposal  and  validation, 
program  directive,  and  project  assignments.  These  three 
activities  are  not  any  different  from  those  previously 
described  in  Chapter  II.  All  Doctrine  starts  as  an  idea 
formally  introduced  as  a  proposal.  Once  the  proposal  has 
been  made,  the  PD  and  project  assignments  are  developed. 
The  difference  with  DCT  enabled  Doctrine  development  is  the 
manner  in  which  the  activities  are  accomplished.  All  the 
activities  in  Phase  One  begin  at  the  same  time. 
Information  and  ideas  are  shared  and  exchanged  continually 
in  the  mutual  environment  created  by  COTS  DCT.  With  an 
application  such  as  Appmail,  the  Fleet  would  be  able  to 
have  some  direct  influence  during  the  Doctrine  development 
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cycle.  As  new  items  are  posted,  actors  in  the  process  are 
able  to  see  new  developments.  As  the  proposal  develops, 
NWDC  can  assign  project  team  members  and  issue  the 
directive  to  create  Doctrine.  The  difference  between  the 
current  Doctrine  process  and  this  process  is  a  reduction  of 
time  in  the  decision  loop.  Take  for  example  the  proposal 
validation  step  in  current  Doctrine  development.  This  step 
has  the  potential  to  backlog  several  actors  waiting  for  a 
response  from  NWDC  and,  if  there  is  a  negative  response, 
the  result  is  a  large  amount  of  wasted  time  and  energy  to 
return  to  the  start.  The  advantage  with  a  COTS  DCT  is  that 
the  developers  of  Doctrine  receive  nearly  immediate 
correction  and  direction.  This  results  in  a  shorter  length 
of  time  in  a  decision  cycle  and  more  time  spent  on 
developing  an  outstanding  document. 

The  next  Phase,  collaboration  to  create,  is  where  the 
Fleet  can  provide  the  most  and  arguably  the  best  input. 
There  are  four  activities;  outline  development,  draft 
development,  review,  and  comment  resolution.  The  outline 
input  and  draft  are  sequential  but  also  simultaneous. 
While  the  draft  requires  an  outline,  draft  development  can 
occur  with  the  parts  of  the  outline  already  approved. 
Review  and  comment  resolution  occurs  throughout  the  entire 
phase  of  collaborate  to  create.  Rework  is  not  eliminated, 
but  turnaround  is  shortened  due  the  near  simultaneous 
processing  features  with  a  COTS  DCT. 

The  third  Phase  in  this  process  is  document 
production.  The  activities  are  endorsement,  approval,  and 
distribution.  These  tasks  are  mostly  administrative.  The 
entire  document  has  been  developed  dynamically  and  the 


39 


approving  authority  has  been  involved  since  the  inception 
of  the  original  idea. 

The  fourth  and  final  Phase  is  the  feedback  and  review 
portion  of  the  Doctrine  development  process.  This  phase  is 
important  because  doctrinal  ideas  continue  beyond 
publication.  There  are  requirements  for  timely  reviews, 
but  this  phase  also  allows  input  based  on  the  intuition  of 
the  sailor  and  DCT  provides  a  portal  through  which  these 
insights  can  pass. 
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Phase  Three:  Document  Production 
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Phase  Tiac:  Collaboration  to  Create 


Process  [Ref.  32] 


C.  THE  VITEPROJECT  MANAGER 

VITEPROJECT  is  the  application  for  modeling  the 
Doctrine  Development  cycle.  VITEPROJECT  Manager  is  a 
management  software  package  with  a  graphical  user  interface 
(GUI)  developed  by  a  group  of  researchers  at  Stanford 
University  [Ref.  32]  .  This  application  is  used  in  this 

study  for  modeling  the  Doctrine  development  process  under 
two  scenarios.  This  software  package  allows  leaders  and 
managers  to  develop  and  test  work  processes  and  related 
organizational  structures  in  a  benign  environment. 
VITEPROJECT  Manager  can  analyze  both  sequential  and 

concurrent  activities.  VITEPROJECT  allows  managers  to 
develop  project  models  to  examine  the  complex  relationship 
between  human  and  task  accomplishment.  Project  managers 
can  identify  shortfalls  and  inefficiencies  in  the  modeled 
plan  through  VITEPROJECT  [Ref.  32] . 

The  user  develops  the  model  using  the  VITEPROJECT 

framework.  The  activity  portion  of  the  model  is  developed 
first.  These  are  the  project's  tasks,  milestones,  and 

meetings.  The  actor  portion  of  the  model  is  developed 
next.  This  portion  contains  the  individuals  and  groups  of 
individuals  involved  with  and  working  on  the  project. 
Table  2  displays  and  defines  the  GUI  for  the  first  two 
portions  [Ref.  32] . 
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Symbolization 

Description 

/  Program  \ 

X  Di  recti  ve  X 

Milestones:  Key  events  or  goals 

that  must  occur  in  the  overall 
process.  [Ref.  32:  p.3-4] 

Outline 

De\/elopment 

Activities:  The  processes  or  work 
accomplished  before  achieving  the 
milestone.  Activities  have  only 
one  actor.  [Ref.  32:p.  3-4] 

— 

Precedence  Relationships:  Defines 
the  flow  of  the  process.  [Ref. 
32 : p .  3-5 ] 

10 

Actors:  People  or  groups  of  people 
that  do  the  work  in  the  activity. 
Each  actor  is  assigned  at  least  one 
activity.  Actors  are  linked  to 
activities  with  a  solid  blue  line. 
[Ref.  32:p.  3-5] 

»r 

Information  Exchanges:  Represents 
communications  and  the  sharing  of 
ideas.  [Ref.  32:p.  3-11] 

s 

/ 

/ 

y 

y 

y 

Dependency  Links:  In  complex 
projects  with  concurrent  processes, 
some  of  the  processes  are  dependent 
upon  the  completion  of  previous 
events  or  activities  [Ref.  32 :p. 
3-11]  . 

I 

1  Meeting2  j 

Meetings:  Meetings  are  linked  to 
actors  by  gray  dashed  lines.  [Ref. 
32:p.  3-13] 

Table  2.  VITEPROJECT  Symbolization  [Ref.  32] 


The  settings  on  the  activity  and  actors  are  adjustable 
to  increase  or  decrease  the  fidelity  desired  for  the 
simulation  and  output  of  the  model.  For  the  purposes  of 
this  research,  the  model  is  set  to  the  default  settings 
[Ref.  32]. 


43 


The  simulation  is  the  next  step  of  the  VITEPROJECT 
model.  At  this  point,  VITEPROJECT  executes  and  simulates 
an  actual  working  environment  with  predictable  coordination 
and  rework  based  on  the  actor  and  activity  models. 
Depending  on  the  model  parameters,  VITEPROJECT  results  are 
as  detailed  and  specific  as  the  parameters  dictate.  The 
detailed  outputs  from  VITEPROJECT  are  displayed  in  Gantt 
charts,  bar  graphs,  and  line  graphs  [Ref.  32] . 

1 .  VITEPROJECT  Model 

This  study  uses  VITEPROJECT  to  model  and  compare  the 
current  method  of  Doctrine  development  and  a  proposed  COTS 
DCT  method  of  Doctrine  development.  The  models  are 
heuristic  and  suggestive.  (There  is  no  single  current 
method  for  developing  Doctrine.  The  actual  processes  thus 
vary  considerably  around  the  ideal  type  presented  as  the 
current  model.)  The  two  models  thus  analyze  total  cost  and 
duration  under  ideal  conditions. 

The  work  process  plan  for  each  scenario  is  represented 
within  the  framework  provide  by  VITEPROJECT.  Thus,  the 
activities,  meetings,  and  milestones  from  figures  5  and  10 
are  placed  into  the  model  [Ref.  32  :p  3-2  to  3-4]  .  The 
organizational  structure  is  created  to  complete  the 
activities  defined  in  the  previous  step.  Because  the  goal 
of  this  research  focuses  on  task-technology  processes 
rather  than  the  assignment  of  responsibility  in  roles,  the 
organizational  structure  was  not  modeled.  Processes  simply 
were  assigned  to  unspecified  "Actors".  Actors  are 
representative  of  the  structural  collection  of  individuals 
and  teams  that  perform  each  activity  [Ref.  32 :p  3-5] . 
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Thus,  the  models  are  set  on  default  settings  to  hold  non¬ 
process  factors  between  the  scenarios  constant. 
Information  exchanges  and  dependency  links  are  inserted  to 
illustrate  the  requisite  interactions  between  tasks  [Ref. 
32 :p  3-11  to  3-12] . 

Figure  11  illustrates  the  linear,  sequential 
functional  flow  of  work  processes  in  the  current  Doctrine 
development  process.  In  this  model,  dependent 
relationships  are  predefined  due  to  the  sequential  nature 
of  the  process  flow.  Meetings  are  positioned  in  the  model 
to  illustrate  the  periodic  need  for  coordination,  project 
re-acquaintance,  and  review.  Meetings  also  represent  time 
away  from  the  project.  Information  exchanges  are  placed 
between  the  following  activities:  Idea  and  Initial 
Proposal ,  Comments  and  Review,  and  Final  Review  and 
Endorsement .  An  idea  is  shared  among  colleagues,  later 
discussed  at  the  NDWP  and  then  becomes  a  proposal;  hence 
the  information  exchange.  Comments  derived  from  reviews 
and  an  exchange  of  information  between  the  reviewers  and 
subject  matter  experts  occur. 
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Figure  11.  Current  Doctrine  Model  [Ref.  32] 

The  DCT  model.  Figure  12,  represents  the  parallel  and 
concurrent  processing  of  activities  during  the  Doctrine 
process.  This  output  oriented  collaborative  model  is 
derived  from  the  process  flow  outlined  by  Figure  10.  This 
model  represents  a  collaborative  effort  across  a  computer 
network,  which  results  in  an  increased  number  of 
information  exchanges.  Networks  enable  collaboration  to 
occur  outside  the  limits  of  physical  co-location.  The  high 
volume  of  Information  Exchanges  and  collaboration  in  this 
DCT  scenario  reduces  the  need  for  face-to-face  meetings. 
Because  this  scenario  is  based  on  work  conducted  across  a 
network,  the  information  is  readily  available  to  users  who 
would  otherwise  have  to  coordinate  through  meetings.  The 
trade  off  between  concurrent  and  parallel  operations 
depends  on  the  relationships  between  the  activities.  The 
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following  activity  pairs  are  dependent  relationships: 
Outline  and  PD,  and  Approved  Document  and  Resolution  of 
Comments.  An  outline  is  not  produced  until  a  PD  is  issued. 
The  document's  approval  rests  with  the  resolution  of  all 
the  comments  made  to  the  draft  document. 


Figure  12.  DCT  Doctrine  Model  [Ref.  32] 

2 .  Analysis  of  COTS  DCT  and  Traditional  Doctrine 

Process  Using  VITEPROJECT  Manager 

The  objective  of  the  analysis  is  to  critically 
contrast  the  overall  flow  of  processes  of  Doctrine 
development  in  the  COTS  DCT  and  traditional  Doctrine 
scenarios.  Timeliness  in  the  development  of  Doctrine  is 
important,  but  the  quality  of  the  Doctrine  is  more 
important.  The  bottom  line  is  quality  Doctrine  driven  by 
quality  content.  The  results  of  this  analysis  are 

displayed  in  the  following  tables  and  figures. 
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Current  Model 

COTS  DCT  Model 

Duration 

Cost 

Duration 

Cost 

19  Months 

168000 

5  Months 

144000 

Table  3.  CPM  Cost  and  Duration  Results  [Ref.  32] 

Table  3  represents  the  Critical  Path  Method  (CPM) 
simulation  results.  The  CPM  simulation  provides  the  user  a 
baseline  on  which  to  compare  the  other  simulation  runs. 
The  CPM  simulation  is  resource-constrained.  Errors, 
coordination,  and  rework  are  not  considered  during  this 
run.  Default  probability  settings  for  error  rates, 
information  exchange  frequencies,  and  noise  are  set  at  zero 
[Ref.  32:  p  3-10]  .  In  other  words,  this  run  represents  a 
perfect  world.  From  Table  3,  it  is  apparent  that  a  COTS 
DCT  process  enables  Doctrine  in  a  world  without  outside 
distractions . 

Table  4  represents  the  results  from  the  same  models  in 
a  simulation  mode.  In  this  mode,  the  probabilities 
mentioned  in  the  CPM  mode  are  reset  to  default  positions. 


Current  Model 

COTS  DCT  Model 

Duration 

Cost 

Duration 

Cost 

20  Months 

216000 

8  Months 

255000 

Table  4.  Simulation  Cost  and  Duration  Results  [Ref.  32] 
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Duration  is  the  same  for  the  simulation  run,  but  the 
costs  associated  with  the  collaborative  model  are  nearly 
doubled.  These  costs  represent  the  increase  in  cost  and 
difficulty  expected  by  coordinating  concurrent 
interdependent  activities  [Ref.  32].  However,  these 
simulations  cannot  accurately  represent  the  cost  savings  of 


a  DCT: 

they 

treat 

each  individual  in 

a  coordinative 

network 

as  a 

single 

entity 

relating  to 

another  single 

entity . 

The 

entire 

reason 

for  a  DCTs 

existence  is  to 

nullify  this  assumption.  The  tool  combines  coordinative 
responses  from  multiple  sources  into  a  single  response, 
thus  dramatically  reducing  costs. 

The  following  Gantt  charts  are  used  to  visualize  the 
results  of  each  simulation  run.  The  left  side  presents  the 
names  of  the  activities  and  milestones  in  their  order  of 
precedence.  The  upper  bar  in  both  charts  represents  the 
CPM  calculations.  Remember  the  CPM  relates  to  perfect 
conditions  in  a  perfect  world.  The  lower  bars  represent 
the  simulation  using  default  settings.  Blue  colored  bars 
represent  non-critical  activities.  Gray  bars  represent 
float  time  for  non-critical  activities.  Critical 

activities  are  shown  in  red.  The  diamonds  represents 

project  milestones.  Gray  diamonds  are  planned  dates  from 
the  CPM  run.  Black  diamonds  are  the  dates  from  the 
simulation  under  default  settings  [Ref.  32:  p.  3-10]  . 
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Figure  13^  displays  the  current  Doctrine  process 
scenario.  The  functionality  of  sequential  processing  is 
exhibited  in  this  chart.  Delays  and  rework  are  not 
illustrated  as  well,  because  the  activity  must  be  completed 
before  being  passed  to  the  next  activity  or  milestone.  The 
information  obtained  from  the  data  above  and  this  Gantt 
chart  reveal  nothing  out  of  the  ordinary.  Sequential  flows 
in  an  ideal  and  perfect  world  are  similar  in  duration  and 
costs . 


Figure  13.  Current  Doctrine  Process  Gantt  Chart 

Figure  14^  is  the  Doctrine  process  with  a  COTS  DCT 
applied.  The  benefits  of  collaboration  are  apparent  as  the 
display  reveals  that  several  activities  become  non- 
critical.  Critical  Paths  are  reduced  through  the  exchange 


^  The  Gantt  chart  is  represented  in  days.  This  allows  display  of  the 
entire  duration. 

2  The  Gantt  chart  is  represented  in  days.  This  allows  display  of  the 
entire  duration. 
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of  information  and  working  activities  concurrently, 
allows  a  more  focused  effort  toward  critical  tasks. 


This 


Figure  14.  DCT  Gantt  Chart 


This  model  is  designed  to  show  benefits  and  trade-offs 


associated 

with 

changing 

an  organization' 

s  way 

of 

processing 

work 

activities 

[Ref 

32]  . 

VITEPROJECT 

illustrates 

that 

the  DCT 

Doctrine 

process 

results 

in 

increased  communications  through  virtual  collaboration. 
The  model  does  show  a  decrease  in  overall  duration  for 
Doctrine  development  due  to  parallel  task  activities  and 
increased  collaboration.  The  model  thus  illustrates  that, 
probably  as  a  worst  case  scenario,  a  small  increase  in 
collaboration  costs  may  be  required  for  potentially  large 
gains  in  the  quality  of  Doctrine,  as  well  as  decreased  time 
to  produce  this  Doctrine. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

This  study  examined  whether  a  COTS  DCT  has  the 
potential  to  more  effectively  and  efficiently  enable  the 
Navy  Doctrine  process.  The  role  of  Navy  Doctrine  is 
crucial  to  the  decentralized  command  and  control  of  a 
network  centric  Navy.  Doctrine  allows  the  Navy's  actors  to 
react  rapidly  and  independently.  Doctrine  provides  Navy 
warfighters  with  the  basic  awareness  to  engage  their 
tactics . 

To  remain  operationally  relevant.  Doctrine  development 
needs  to  parallel  the  changing  technological  environment. 
The  traditional  way  of  creating  Doctrine  is  slow  and  time 
consuming.  NWDC  initiated  WED  to  enhance  the  Doctrine 
development  process  by  garnering  Fleet  input. 

Current  WED  is  based  on  the  traditional  Doctrine 
process  as  discussed  in  Chapter  II.  It  consists  of 
threaded  discussions  concerning  Doctrine  development.  The 
current  design  of  WED  has  not  alleviated  delays  in  Doctrine 
development.  Fleet  input  has  not  been  as  robust  as 
anticipated.  In  order  for  the  WED  to  be  an  output-oriented 
process  with  high  levels  of  Fleet  involvement,  we  argue 
that  the  Navy  needs  to  implement  a  collaborative  Doctrine 
development  environment. 

There  are  many  COTS  DCTs  available  that  can  be  adapted 
to  the  WED  process.  A  COTS  DCT  based  WED  can  enhance 
overall  effectiveness  and  efficiency  in  the  Doctrine 
development  process  as  suggested  by  the  VITEPROJECT 
simulations . 
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A  more  precise  estimate  of  cost  savings  could  be  made 
if  more  realistic  data  on  times  and  task  flows  could  have 
been  collected  and  used  in  the  modeling  process.  In 
addition,  identifying  specific  actor' s  roles  and  skills  and 
their  relationships  in  their  hierarchy  could  generate  a 
higher  fidelity  model.  None-the-less ,  in  the  absence  of 
the  availability  of  data,  the  idealized,  simplified 
simulation  heuristically  illustrates  that  the  DCT  WED 
scenario  produces  gains  in  timeliness  of  Doctrine  through 
the  parallel,  collaborative  work  processes.  These 
collaborative  processes,  although  not  free,  are  viewed  as 
being  very  inexpensive  for  the  expected  gains  in  quality, 
thanks  to  the  DCT.  Thus,  VITEPROJECT  manager  illustrates 
how  the  DCT  Doctrine  process  has  the  potential  to 
efficiently  enable  an  increase  in  communications, 
efficiency  and  quality  of  Doctrine  through  virtual 
collaboration . 

The  benefits  of  creating  Doctrine  collaboratively 
through  a  COTS  DCT  can  enable  the  Fleet  to  actively 
participate  in  developing  Doctrine.  A  web-based  process 
can  enable  the  Fleet  to  view  and  offer  input  to  enhance  the 
incorporation  of  emerging  technologies.  The  continuous 
review  capability  offered  by  a  DCT  increases  the  likelihood 
of  a  quality  Doctrine  being  produced.  Increased 
collaboration  decreases  the  number  of  critical  paths  due  to 
increased  information  flows. 

Collaborative  production  methods  are  output  oriented. 
Since  Doctrine  is  content  driven,  implying  an  output 
orientation,  the  Doctrine  development  process  should  be 
accomplished  through  a  collaborative  environment.  We  have 
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shown  that  a  DCT  such  as  Zaplet  can  be  adapted  to  provide  a 
cost  effective,  time  saving,  easy  to  use  environment  for 
Doctrine  development. 

B.  RECOMMENDATIONS 

The  vision  of  NCO  is  leading  the  Navy  towards  a  more 
collaborative  and  network  centric  foundation.  Computers 
and  networked  information  centers  are  becoming  commonplace. 
Budgetary  constraints  and  the  political  environment  are 
forcing  all  DoD  agencies  and  entities  to  use  innovative 
technology . 

COTS  DCT  enables  the  Navy  to  work  smarter.  The  Navy's 
workforce  can  benefit  greatly  from  the  incorporation  of 
commercial  technologies  in  the  work  place.  Creating 
Doctrine  collaboratively  demonstrates  an  appropriate 
"intelligence  over  force"  concept.  For  example,  COTS  DCT 
results  in  fewer  meetings.  Collaboration  improves  Doctrine 
by  gathering  the  insight  and  needs  of  warfighters. 

There  are  several  COTS  products  available  in  the 
marketplace  today.  This  study  concentrated  on  the  Zaplet 
Appmail  Suite™.  Zaplet' s  product  easily  assimilates  to 
the  Navy's  needs.  This  product  works  with  established 
systems  in  the  Navy,  such  as  Microsoft  Outlook.  Several 
corporations  use  Zaplet' s  product.  U.S.  Government 
agencies  such  as  the  Central  Intelligence  Agency  (CIA)  are 
beginning  to  use  Zaplet  as  well  [Ref.  29] . 

This  thesis  thus  recommends  strong  consideration  of 
COTS  DCT  for  further  research  and  inclusion  into  the  WED 
Doctrine  development  process. 

C.  SUGGESTED  FURTHER  STUDIES 
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Several  areas  of  this  study  lend  themselves  to 
expansion  for  further  research.  Most  obviously,  models 
could  be  developed  in  closer  cooperation  with  the  Doctrine 
command  in  order  to  manipulate  and  analyze  tasks  at  a  finer 
resolution  and  to  examine  alternative  organizational 
structures.  This  might  identify  additional  changes  in  work 
and  organizational  processes  that  would  further  enable  a 
higher  quality  Doctrine  product.  Additional  studies 
incorporating  test  case  or  use  analysis  using  projects 
currently  in  the  Doctrine  process  would  be  beneficial. 
Such  studies  would  require  a  more  careful  cost  analysis  and 
might  contrast  a  COTS  DCT  versus  the  traditional  Doctrine 
process.  This  type  of  study  can  determine  if  a  COTS 
product  is  more  cost  effective  vice  a  custom  developed 
product . 

This  study  discusses  the  security  features  associated 
with  Zaplet ' s  Appmail  application.  The  application  uses 
industry  standard  levels  of  security.  An  in  depth  study  of 
security  issues  and  COTS  DCTs  is  suggested.  Use  analysis 
or  incorporating  a  COTS  DCT  in  the  WED  process  can  be 
determine  if  the  application  is  compatible  with  the  Navy's 
security  standards. 
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APPENDIX 


ACRONYMS  &  ABBREVIATIONS 


C2 

CC 

CINC 

CINCLANTFLT 

CINCPACFLT 


Command  and  Control 

Contributing  Command 

Commander  in  Chief 

Commander  in  Chief  Atlantic  Fleet 

Commander  in  Chief  Pacific  Fleet 


CINCUSNAVEUR  Commander  in  Chief  U.S.  Navy  Europe 


COA 

COC 

COMUSNAVCEN 

COTS 

CPM 

CRA 

DCT 

DoD 

EBO 

ESC 

EASA 

EBE 

EEDSPECS 

GCCS 

GUI 


Course  of  Action 

Chain  of  Command 

Commander  U.S.  Navy  Central 

Commercial  Off  the  Shelf 

Critical  Path  Method 

Coordinating  Review  Authority 

Distributive  Collaborative  Technology 

Department  of  Defense 

Ef f ects-based  Operations 

Executive  Steering  Committee 

Eederal  Streamlining  Acquisition  Act 

Fleet  Battle  Experiment 

Federal  Specifications 

Global  Command  and  Control  System 

Graphical  User  Interface 


57 


MILSPECS 

NCO 

NDP 

NDWP 

NLL 

NLLS 

NTTP 

NWDC 

NWP 

OPNAV 

PCO 

POC 

PRA 

R&  D 

RMA 

SEI 

TCO 

TTP 

U.S. 

VTC 

WED 


Military  Specifications 

Network  Centric  Operations 

Naval  Doctrine  Publication 

Navy  Doctrine  Working  Party 

Navy  Lessons  Learned 

Navy  Lessons  Learned  System 

Navy  Tactics,  Techniques,  and  Procedures 

Navy  Warfare  Doctrine  Command 

Naval  Warfare  Publication 

Office  of  the  Chief  of  Naval  Operations 

Platform-centric  Operations 

Point  of  Contact 

Primary  Review  Authority 

Research  and  Development 

Revolution  in  Military  Affairs 

Software  Engineering  Institute 

Technical  Cognizant  Office 

Tactics,  Techniques,  and  Procedures 

United  States 

Video  Tele-Conference 

Web-Enabled  Doctrine 
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